Elasticsearch Service と CloudSearch どっちを選べば良いの？

こんにちは、木戸です。

AWS の検索エンジンをベースとしたサービスには、Amazon Elasticsearch Service と Amazon CloudSearch の２つがあります。今回はこの二つのサービスについての用途の違いについてまとめたいと思います（機能比較ではないです）。サービスを選定する際の参考になれば幸いです。

※ Elasticsearch Service は Kibaba も含め分析用途もありますが、今回は検索にフォーカスしてます。

それではさっそく、

CloudSearch も Elasticsearch も Lucene ベース

CloudSearch は現在 Solr ベースとなっており、その検索エンジンのコアには Lucene を使用している。また、Elasticsearch も Lucene をバックエンドに使用しているため、ベースのテクノロジーとしてはそれほど大差はない。

決まった仕様の CloudSearch VS 高いカスタマイズ性の Elasticsearch

一言でそれぞれのサービスを表すなら CloudSearch は「サイト内検索アプリケーション向けサービス」、Elasticsearch Service は「検索エンジンプラットフォームサービス」です。

ブログのシステムに例えるなら、記事を投稿する機能、記事を公開する機能、コメント機能など、ある目的のために設計されたアプリケーションが CloudSearch だとすると、Elasticsearch Service は素のデータベースの位置付けに近く、データを保存する機能、参照する機能などブログシステムを構築するための機能は兼ね備えているが、それを使ってどんなアプリケーションを開発するかは開発者の設計に委ねられているのが Elasticsearch Service と言えるのではないだろうか。

そのため、CloudSearch はサイト内検索で必要な機能セットがすでに用意されていて、検索要件がマッチすれば Elasticsearch Service と比べると、ほとんど設計することなく利用することができる。例えば日本語の文章を対象に意味のある単語で検索（形態素解析によるインデックス化と検索）したければフィールドの言語処理オプションを日本語にするだけだ。

一方 Elasticsearch Service は、単に日本語の文章を対象に意味のある単語で検索したいだけだとしても、その要件にあわせた言語処理を利用者が設計する必要がる。しかし、文字列を部分的に一致させて検索漏れを極力減らしたいといった要件が発生した場合、N-Gram 方式（文字列をN文字単位にトークン化して部分的にマッチさせる方式 ≒ Like 検索）など別の言語処理を設計し適用することが可能なため、検索精度がサービスの仕様に依存する CloudSearch に比べカスタマイズしやすい。

１対多のデータ構造対応なら迷わず Elasticsearch

CloudSearch は、テキスト型や日付型、数字型（int/double）、それに加えそれぞれの値を複数格納できる配列型などが用意されているが、基本的には１つのドキュメントはフラットな構造のみサポートしている。

一方、Elasticsearch Service は、それらのデータ型に加え、ネストされたオブジェクト型や親子関連のインデックスをサポートしているため、１つのドキュメントに対して、１対多の関連を持った情報も正確にフィルタリングしたり、ソート条件として使用できる。

一般的にフラットな構造の商品検索では、CloudSearch、Elasticsarch Service ともに候補にできるが、例えば旅行サイトのツアーやチケット検索のように、一つの商材に対して、期間と価格の組み合わせを複数持つようなデータ構造の場合、Elasticsearch Service のみが候補としてあげられる。

運用で楽がしたい場合は CloudSearch

運用面でも違いがある。CloudSearch は完全マネージド型のサービスのため、データ量や検索トラフィックに対して自動でスケールしてくれるためシステムの運用負荷は少ない。

一方 Elasticsearch Service 障害が発生したノードを自動的に検出および交換してくるため、自己管理のインフラを運用するのに比べると運用負荷は少ないが、必要なサーバー台数を決定するのは利用者の判断に委ねられる。

また、シノニム辞書の追加・更新など、CloudSearch の場合は自動で再インデックスされ、追加された辞書の内容が反映される仕組みとなっているが、Elasticsearch でインデックス側にシノニム辞書を適用する仕組みとして設計した場合、複数の API を使用して、再インデックス処理をオペレーションするか、別のインデックスを作成して、シノニム辞書適用後、エイリアスを使って現在使っているインデックスと切り替えるなどのアプリケーション的な運用面も考慮する必要がある。

後者は一見面倒な仕組みに思えるが、シノニム辞書を適用する場合、登録する内容によっては検索結果に与える影響が大きくなることもあるため、新しいシノニム辞書の適用を検証してから本番へ公開するなどといった運用フローにも柔軟に対応出来る良い面もある。

まとめ

どちらが優れている優れていないと言うものでもないので、カスタマイズ性を重視するのか、検索機能はサービスに任せて、フロントのアプリケーションの開発に注力するのかなど、上記の内容を加味して選定していただければ良いのではないかと思います。

また、CloudSearch に比べ、Elasticsearch Service はカスタマイズ性に優れているとは言え、まだリリースされて１年も経っていないので、Elasticsearch をEC2へセットアップして使用するのに比べ、その機能面における制限はまだまだ多いのも現実。

Elasticsearch の機能をフルに活用しつつ完全マネージド型のサービスが使いたいというわがままな方向けには、Elastic社の提供する Elastic Cloud (元 Found) もあるのでこちらも検討してみてはどうだろうか。